Using the HomeLending database, we will implement cell-level encryption. For simplicity and clarity we will focus on the Borrower_Identification
table. The majority of the steps noted in this demonstration would be
repeated as needed for each column in any table that contains data
classified as "High" sensitivity.
Before we begin, we will need
to examine our database and generate the requirements that will guide
our approach to implementing cell-level encryption.
Reviewing the Borrower_Identification Table
The Borrower_Identification
table contains references to a borrower's various forms of
identification, such as Security Number, Driver's License Number and
Unique Tax Identification Number.
The columns defined in this table are as follows:
Borrower_Identification_ID: The primary key, containing an integer value that uniquely identifies each row.
Sensitivity class: medium, due to our defined default class.
Borrower_ID: An integer value; this is the foreign key, relating to rows contained within the Borrower table.
Sensitivity class: medium, due to our defined default class.
Identification_Type_ID: This integer value identifies the type of identification that is stored in the Identification_Value column. Through this foreign key to the Identification_Type table the verbose reference of the identification type, such as "Social Security Number" can be obtained.
Sensitivity class: medium, due to our defined default class.
Identification_Value:
This variable character value contains the plain text representation of
the actual identification value. For example, if the identification
type was a Social Security Number the value contained in this column
would be something like "555-55-5555".
Sensitivity class: high.
Through the grouping
of logically similar columns, the use of a unique row identifier, the
absence of repeating columns, the use of foreign keys and the fact that
the columns contained within this table are dependent only upon the
primary key, we can see that this table has achieved third normal form.
This level of
normalization has provided a separation of this sensitive data from data
that is classified with a lesser level of sensitivity. It also confers
the benefits of our first requirement:
Requirement 1: Permission to Modify Sensitive Data
The only individuals that will update or insert data into tables containing high sensitivity columns will be members of the Sensitive_high database role.
The normalization that has been achieved for the Borrower_Identification table is representative of the other tables that have been created throughout the HomeLending database.
Database Object Access Control
Direct access to all tables within the HomeLending database has been denied to the members of the Sensitive_high, Sensitive_medium and Sensitive_low database roles. An example of the script that was used on the Borrower_Identification table is shown in Listing 1:
Views and stored procedures
will be developed that provide the means by which our users will
interact with these tables. By implementing this structure we can
control the access to our data at a more granular level than simply
granting access to entire tables. In addition, this architecture affords
us the opportunity to embed cryptographic functionality, and other
logical methods, into objects such as views and stored procedures.
This provides us with our second requirement:
Requirement 2: Access to Base Tables
All users will be denied
access to all base tables. Access to data will be mediated through the
use of views and stored procedures.
Key Encryption and Performance
Performance is king when
it comes to databases. When transaction volumes are extremely high,
performance is elevated to an even higher level of importance and
security of sensitive data often takes a back seat. Indeed, there is a
cost to implementing encryption. However, our goal within the HomeLending database is to implement cell-level encryption in such a way that it has minimal impact on performance.
Asymmetric key encryption is
based on a complex algorithm and provides a very high level of
protection. However, with this complexity comes a commensurately high
processing cost.
The strength of
symmetric key encryption is dependent upon the length of the keys that
are used. The lengthier keys provide a higher level of security but,
again, come with a higher processing cost. Symmetric key algorithms are
in general less complex and therefore weaker than those for asymmetric
keys, which results in faster processing.
When dealing with large
volumes of data and transactions, the tremendous affect asymmetric keys
have on performance is often too high a price to pay for the stronger
encryption that they provide. Therefore, we arrive at our third
requirement:
Requirement 3: Encryption Algorithms
All High sensitivity data
will be protected with a symmetric key that utilizes the AES algorithm.
This results in a key length of 128 bits, which is consistent with
specifications defined by regulations, industry standards and corporate
policies.
Determining the Key Hierarchy
In SQL Server, the use of
symmetric key encryption requires that the key be opened prior to use.
Once a key is opened it remains open until the database connection is
terminated or it is explicitly closed. Leaving a key open for the
duration of a session does provide a level of convenience, but also
introduces a degree of vulnerability to "hacking." As such, it is
recommended that you explicitly close keys as soon as you have finished
using them.
Symmetric keys are protected
by other keys, certificates or a password. This prevents the
unauthorized use of a key to encrypt and decrypt sensitive data. This
also presents a challenge when implementing and maintaining the related
code that uses the keys.
If a key is protected by a password, the stored procedures that use the OPEN SYMMETRICKEY method would either have to:
Obtain the password from another source
Have the password hard-coded into the code
Require the password to be passed as an argument to the stored procedure.
Obtaining the password
from another source would require additional resources that could
negatively affect the performance of our cryptography functionality. The
hard-coding of passwords presents a maintenance nightmare, as well as
security concerns regarding plain text passwords being embedded in our
code. A hacker who is tracing database activity will be able to
intercept a plain text password that is being sent as an argument to a
stored procedure. If the password is passed as a hashed value, that too
adds additional resources.
Our understanding of the
encryption key hierarchy,will help
us overcome this challenge. The service master key, which was
automatically generated when our instance was installed, can be used to
protect a database master key. A database master key can be used to
protect a self-signed certificate, which in turn can be used to protect
our symmetric key. This hierarchy not only provides a seamless and
maintainable structure, but it also reduces the possibility that the
sensitive data can be disclosed externally from the database and
instance.
Therefore, we arrive at our fourth requirement:
Requirement 4: The Encryption Key Hierarchy
All symmetric keys
that are used to protect sensitive data will utilize the encryption key
hierarchy and be protected by a self-signed certificate that is secured
by the database master key. The database master key will be protected by
the service master key.
